https://parentheticallyspeaking.org/articles/bicameral-not-homoiconic/<section class="SsectionLevel1" id="section 0" morss_own_score="6.811545431012166" morss_score="37.90960185563779"><h1><a href="https://parentheticallyspeaking.org/articles/bicameral-not-homoiconic/#(part._bicameral)" title="Link to here">🔗</a> </h1><p>If you spend enough time reading internet discussions of programming languages, you’ll learn that Lispy languages have a special property: they are <span>homoiconic</span>. This property is vested with mystical powers that both enrich Lisps and debase its competitors.</p><p>I have programmed in, and built, Lisps since the late 1980s. My blog is called “parenthetically speaking”. And yet I’m here to tell you that this term is mostly nonsense. However, there <span>is</span> something special—</p><section class="SsectionLevel2" id="section 1" morss_own_score="6.8133333333333335" morss_score="36.48"><h2>1 <a href="https://parentheticallyspeaking.org/articles/bicameral-not-homoiconic/#(part.__.Weak__.Homoiconicity)" title="Link to here">🔗</a> </h2><p>What, supposedly, is homoiconicity? You will hear things like: the property that “a property of some programming languages that allows programs to be represented as data within the language”, or with “represented” substituted by “manipulated”, or more simply as “code as data”.</p><div>Let’s tease these apart a bit. Consider the following Python code: </div><table><tr><td><p><span>hello = 1</span></p></td></tr></table><div>This is clearly a program. But can I <span>represent</span> this as a datum within the language? Sure: </div><table><tr><td><p><span>'hello = 1'</span></p></td></tr></table><div>is a perfectly good representation. (Well, it may be <span>good</span> but it’s not <span>great</span>; we’ll return to that!) Can I <span>manipulate</span> it? Sure, I can concatenate strings to create it: </div><table><tr><td><p><span>'hello' + ' = ' + '1'</span></p></td></tr></table><div>will produce that program, and </div><table><tr><td><p><span>'hello = 1'.split(' ')</span></p></td></tr></table><div>will take it apart into constituent pieces.</div><p>Does that make Python homoiconic?</p><p>Of course, there’s nothing special about Python here. We can use JavaScript to represent and manipulate JavaScript programs, C to do the same to C programs, and so on. Essentially, any programming language with a string datatype seems to be homoiconic. Heck, we didn’t even need strings: we could just as well have represented the programs as numbers (e.g., using <a href="https://en.wikipedia.org/wiki/G%C3%B6del_numbering">Gödel numbering</a>).</p><p>One of the traits of a good definition is that it be non-trivial: it must capture some things but it must also exclude some things. It’s not clear that this notion of homoiconicity excludes much of anything.</p></section><h2>2 <a href="https://parentheticallyspeaking.org/articles/bicameral-not-homoiconic/#(part.__.Strong__.Homoiconicity)" title="Link to here">🔗</a> </h2><p>But there’s a reasonable objection to what we wrote above. All that we’ve done is written, combined, and taken apart <span>strings</span>. But strings are not necessarily <span>programs</span>; strings are just strings, a form of data. Data are data, but programs—<span>run</span>—</p><p>How do we turn data into programs? We do need some language support for that. We need something that will take some agreed-upon data <span>representation</span> of a program and <span>treat it like a program</span>, i.e., do whatever the program would have done. Typically, this is a function called <span>eval</span>: it evaluates the datum, performing the effects described in the datum, just as if it were a program. (Note that <span>eval</span> really treats “data as code”, not “code as data”.)</p><div>So maybe <span>eval</span> is the real characteristic of homoiconic languages? Maybe. It’s certainly true that <span>eval</span> is a distinctive feature, and some languages have it while others don’t: that is, it non-trivially distinguishes between languages. But it’s worth noting: </div><ul><li><p>Many languages, including Python and JavaScript, have an <span>eval</span>. If they’re all homoiconic, then clearly this isn’t a particularly Lispy trait.</p></li><li><p><span>eval</span> interacts poorly with its lexical environment, thereby making it hard to even program with effectively. <a href="https://cs.brown.edu/~sk/Publications/Papers/Published/pclpk-s5-semantics/">We showed</a> that JavaScript’s <span>eval</span> is not one but four operations and there are eight contexts that determine which of the four to use. This kind of complexity is overwhelming.</p></li><li><p>The complexity might be worth it if <span>eval</span> were a good idea, but it’s often a bad idea in programs! It makes code statically invisible, making every other aspect of program management—</p></li></ul><div>This seems like a disappointing way to end: homoiconic languages are ones that have a complex, excessively-powerful feature that we probably shouldn’t use but is anyway found in many languages that are not Lispy at all…which certainly doesn’t seem to be a good way to describe what makes Lispy languages distinctive.</div><p>But this just shows why we shouldn’t be talking about homoiconicity at all. Let’s talk about what’s actually interesting instead.</p><section class="SsectionLevel2" id="section 3" morss_own_score="6.8539130434782605" morss_score="42.35391304347826"><h2>3 <a href="https://parentheticallyspeaking.org/articles/bicameral-not-homoiconic/#(part._.The_.Parsing_.Pipeline)" title="Link to here">🔗</a> </h2><p>Let’s talk briefly about the classical parsing pipeline. For decades, we’ve been taught to think of parsing a program as having two phases: tokenization (sometimes colloquially called “lexing”) followed by parsing (<span>not</span> colloquially called “yaccing”), and more. What do they do?</p><p>A program is a list, or stream, of characters. A language implementation needs to first understand what a program is saying before it can make the program do what it says. That is, it has to understand the meaning of a program. This process of determining meaning is usually done in several stages, which make sense once we understand them in terms of their expressiveness.</p><p>A typical dataflow in the front-end of a language implementation looks like this:</p><blockquote><p><img src="https://parentheticallyspeaking.org/articles/bicameral-not-homoiconic/pict.png"></p></blockquote><p>What does this mean?</p><p>Just as you don’t read this article at the level of individual letters, given a program like <span>hello = 1</span>, we don’t want to deal with it at the level of each <span>letter</span>: <span>h</span>, <span>e</span>, <span>l</span>, … either. Instead, we’d like to start by thinking of it as having three <span>tokens</span>: <span>hello</span>, <span>=</span>, and <span>1</span>. Note that in the process, we can ignore whether or not the <span>=</span> was surrounded by spaces (which Python does not require, but some languages do).<span>We’ll return to the elided spaces later!</span> This is the job of the <span>scanner</span>.</p><p>So the input list or stream of characters gets transformed, by the scanner, into an output list or stream of tokens. But as a reader, you still don’t really read the program at the level of tokens; instead, you assign <span>meaning</span>. That is, you presumably read the above as “assign <span>hello</span> to <span>1</span>”.<span>The actual meaning of <span>=</span> in Python is much more messy.</span> This is the job of the <span>parser</span>: to create a data structure representing the high-level semantics of the language. In this case, it might create an abstract syntax tree of a “variable assignment”-type node with two children, one the variable being assigned (here, <span>hello</span>) and one the value expression (here, just <span>1</span>). If the actual expression were more complicated—<span>hello = 1 + 2</span>—<span>This being Python, of course the actual meaning of <span>+</span> is also messy.</span></p><p>The exact mechanisms by which this form of parsing happens is somewhat outside scope here. For many languages, grammars are ambiguous and top-down parsing strategies—</p><div>Not every language implementation follows the above pipeline. People have, for instance, experimented with <a href="https://en.wikipedia.org/wiki/Scannerless_parsing">parsing without using a scanner</a>. Both conceptually and practically, it is still useful to have this separation: </div><ul><li><p>The scanner usually sits at the lowest level of the Chomsky hierarchy: it is regular. It is therefore quick and efficient and its rules are easy to reason about in depth.</p></li><li><p>The parser, in contrast, is usually context-free or worse, making it a much more complicated beast.</p></li></ul><div>We should want to take advantage of complexity theory in building our tools! This also represents a good separation-of-concerns, whereby we could imagine building multiple parsers—</div><p>In what follows, therefore, I will take the scanner as a given. Thus, the traditional pipeline then has just one stage: the parser. I therefore call this the <span>unicameral</span> pipeline.</p></section><h2>4 <a href="https://parentheticallyspeaking.org/articles/bicameral-not-homoiconic/#(part._.The_.Bicameral_.Analogy)" title="Link to here">🔗</a> </h2><p>Many countries have what is called a <span>bicameral</span> legislature: “bi” meaning two, “camera” meaning room. That is, there are two houses of parliament. India, for instance, has the Lok Sabha and Rajya Sabha; England has the House of Commons and House of Lords; the USA has the House of Representatives and Senate. In all cases, there is a “lower” house and “upper” house.</p><p>My goal here is not to endorse various class-related associations or to delve into the actual practices, but rather to employ this as a useful, rough analogy. A theory of bicamerality is this. The lower house is a bit more rowdy and boisterous. It filters out some of the more absurd legislations, but it allows through many that are perhaps not entirely wise. The upper house is more calm and deliberative; in legislatures, its members are either appointed or serve longer terms, so they do not need to bend to every populist will. Therefore, the upper house usefully serves as a filter.</p><p>So: we have two houses. The lower house filters out dreck, but lets through several bills, some of which are unwise. The upper house passes judgment on these bills, allowing only the ones it considers wise. Enough political science, back to computer science.</p><section class="SsectionLevel2" id="section 5" morss_own_score="6.988095238095238" morss_score="73.39835164835165"><h2>5 <a href="https://parentheticallyspeaking.org/articles/bicameral-not-homoiconic/#(part._.Bicameral_.Syntax)" title="Link to here">🔗</a> </h2><p>As I’ve alluded above, having just a parser gives you a unicameral syntax. What Lispy languages give you is a <span>bicameral</span> syntax. But they are not unique in this; other notations, such as XML and JSON, are also bicameral. To make my point, I will use these other notations.</p><p>First of all, all these notations have to get through a scanner. In XML, you can’t write <span>&lt;title</span> <span>without</span> a closing <span>&gt;</span>; that’s just not even a valid opening tag. In JSON, you can’t write <span>"hi</span> without a closing <span>"</span>; that’s just not a valid string. We can think of these as basic tokenization failures. So let’s assume our input passes the scanner and we get a list or stream of tokens.</p><div>Even once you’ve written proper tokens, there are still things you cannot do in XML or JSON. For instance, the following full document is not legal in XML: </div><table><tr><td><p><span>&lt;foo&gt;&lt;bar&gt;This is my bar&lt;/bar&gt;</span></p></td></tr></table><div>because we didn’t “close” <span>&lt;foo&gt;</span> with a <span>&lt;/foo&gt;</span>; this isn’t legal either, </div><table><tr><td><p><span>&lt;foo&gt;&lt;bar&gt;This is my bar&lt;/foo&gt;&lt;/bar&gt;</span></p></td></tr></table><div>because we didn’t preserve the nesting structure (we should close <span>bar</span> before we close <span>foo</span>). The same is true in JSON: we can’t open a structure without closing it (or vice versa); similarly, we have to close braces and brackets in the opposite order of how we opened them.</div><p>Observe that we can make these judgments <span>without knowing what the datum represents</span>. There’s a reason I used names like <span>foo</span> and <span>bar</span> instead of something meaningful. That’s because it doesn’t matter: these XML and JSON data are wrong at a <span>basic</span> level. We say that they fail to be <span>well-formed</span>. This is our lower house.</p><p>However, there may be more complicated rules at play. It may be that a <span>bar</span> really should not reside within a <span>foo</span>; it may be that every <span>baz</span> requires one or more <span>quux</span>es. If you’ve ever worked with an XML or JSON format, you know that there are all kinds of rules like this (that may or may not have been documented well!) that you need to follow. For instance, when you read the documentation of a Web API, it might tell you that a certain kind of request needs to provide certain fields, but must also <span>not</span> provide certain other keys. All these are called rules of <span>validity</span>. They build on top of—</p><p>This leads to a new pipeline, one where some tool performs an intermediate check for well-formedness, and another for validity. The last stage—<span>reader</span>:</p><blockquote><p><img src="https://parentheticallyspeaking.org/articles/bicameral-not-homoiconic/pict_2.png"></p></blockquote><p>Now, as written, it’s not clear what the output of the reader is. It could be that the reader just <span>checks</span> the tokens, and then passes on the same token list or stream to the parser, just as in the previous pipeline. But this would be a loss! The reader has the ability to construct an extremely useful intermediate data structure. The main property the reader looks for is that “things match up and nest properly”. In other words, the reader is confirming that the input is a <span>tree</span>. Thus, instead of passing on a dumb, flat list of tokens to the parser, it constructs trees.</p><p>This greatly simplifies the job of the parser for two reasons. At a more basic level, some of the checking that the parser previously had to do is already done. More interestingly, tokens are very low-level; trees are high-level. It’s much easier to write a recursive function that checks for validity and produces abstract syntax trees when already given well-formed trees as an input!<span>For this reason, <a href="https://plai.org/">PLAI</a> calls this the “Primus Inter Parsers”, a joke that seems lost on most.</span></p><div>Again, complexity theory is a useful guide, and what we have done is steadily ratchet up the complexity: </div><ul><li><p>The scanner is still regular, with all the attendant benefits and weaknesses.</p></li><li><p>The reader is context-free. It does not need to do more than that.</p></li><li><p>The parser is now freed of basic context-free checks, and can focus on other context-free and, in particular, context-<span>sensitive</span> checks.</p></li></ul><div>And once again, we can exploit this separation of concerns to swap out other implementations if we need to.</div><p>This, then, is a <span>bicameral syntax</span>. The reader is the “lower house”; it rejects basic mistakes, but still lets through some invalid things. But it also presents them wrapped up in a cleaner, simpler structure to work with. The parser is the “upper house”; it receives this clean structure and can look for deeper flaws in it, only allowing those things that pass its more exacting scrutiny.</p><div>The advantages to a bicameral syntax are many: </div><ul><li><p>We get a greater separation of concerns, making it easier to both understand and to swap out components.</p></li><li><p>We get to more gradually walk up the complexity hierarchy.</p></li><li><p>The reader sits at a key intermediate level, turning tokens into trees, thereby greatly simplifying the parser’s task while itself being quite easy to write.</p></li></ul><p>This simplicity of (correct!) implementation matters! It doesn’t matter as much when you have only one implementation of a language. However, a lot of our traffic in computing is best represented as trees: they are much more powerful than strings, but also simple enough to write and read. It is therefore no surprise that bicameral syntaxes like JSON have become ubiquitous. <span>Every</span> language now needs a reader for them, and these readers have to implement the same language, so simplicity of specification and of implementation are a virtue. In turn, many systems need to separately validate a JSON input; again, the simplicity of writing this kind of (tree-consuming) parser is a big win.</p><p>This additional level also has other tooling advantages. It’s not only language implementations that need to support syntax; so do editors. It’s a lot easier to support matching, indentation, coloring, and so on at the well-formedness level. And it’s <span>easy</span> to indent trees! It’s also easy to traverse them: there are meaningful <span>generic</span> tree-level operations (“go to the opening”, “go to the closing”, “go up a level”, “go down a level”, etc.) that can be applied to all languages with the same well-formedness characteristic (e.g., JSON). And again, we have lots of editors, and they each need to support the same syntaxes; bicameral languages, by providing the intermediate notion of well-formedness, let tools hit the trifecta of: correct, useful, and relatively easy.</p><p>These advantages are offset by one drawback: some people just don’t <span>like</span> them. It feels constraining to some to always write programs in terms of trees, rather than more free-form syntax. Even in this bicameral space, there are trade-offs: XML requires you to repeat tags at closing, which improves error-checking and catches errors in refactoring, but makes authoring painful; Lisps don’t require tag repetition but, traditionally, use only one kind of parenthesis, making structure harder to see; JSON mixes delimiters while avoiding closing tags, which seems to be some kind of sweet-spot (because it still provides some checking against editing errors). Still, what people are willing to embrace for writing data seems to irk them when writing programs, leading to the long-standing hatred for Lispy syntaxes.</p></section><h2>6 <a href="https://parentheticallyspeaking.org/articles/bicameral-not-homoiconic/#(part._.Back_to_.Lisps)" title="Link to here">🔗</a> </h2><p>We started with Lisp, so let’s go back there. What is Lisp? Lisp is a feeling, an emotion, a sentiment; Lisp is a vibe; Lisp is the dew on morning grass, it’s the scent of pine wafting on a breeze, it’s the sound of a cricket ball on a bat, it’s the…oh, wait, where was I. Sorry.</p><p>Okay, seriously. Note that I keep writing “Lispy languages”: both the “y” and “[language]s” should have stood out by now. What do I mean by this?</p><p>I’m not referring to a particular language: Common Lisp, say. I’m referring to a family of languages, which includes Common Lisp but also Scheme and Racket and Clojure and many others. This family is bound by some cultural antecedents, but the individual languages can be wildly different. What they share is a <span>philosophy of syntax</span>. And now that we’ve fleshed out that philosophy, if we are being generous, we could allow that <span>any</span> bicameral language is at its essence “Lispy”.</p><p>The power of this philosophy is that the language platform can implement its bicameral syntax once, and well, and lots of languages can inherit it. We noted above that there are many (data) languages built atop JSON, each of which has its own validity rules. We can likewise build many data and programming languages atop any bicameral syntax; they will share some familial traits but differ quite a bit in the details.</p><div>The bicamerality of Lisps, however, leads to some misconceptions: </div><ol><li><p>It does not dictate a particular implementation strategy. For instance, the argument in Lisp sometimes goes, “code is data because code is represented using s-expressions, which are also Lisp data”. A full tutorial of what these terms means is beyond what I want to get into here. What I will just say is that there are Lispy languages where this is not true at all.</p><p>The one I know best is Racket, because I originally built some of these parts of it. In Racket, code is not represented using s-expressions. This is because “code” requires many more things: it needs, for instance, to record the source locations so that it can use it to report errors;<span>Remember those whitespaces we said we could ignore? We can’t if we want to report errors!</span> it needs hygiene information to avoid inadvertent capture; and more. Therefore, Racket has a notion of <a href="https://docs.racket-lang.org/reference/stxops.html"><span>syntax</span> object</a> (which, yes, is a datum) that captures this much richer notion of “program source”. Syntax is a separate type that happens to parallel (and enrich) s-expressions and can be interconverted with them, but it is not an s-expression. So, while there is a large family of functions that operate on (say) lists, and s-expressions include lists, none of those functions will apply to syntax.</p></li><li><p>People will sometimes say that the <span>read</span> primitive “parses”. It does not: it reads. It “parses” inasmuch as it confirms that the input is well-formed, but it is not the parser of convention—</p><p>To make this concrete, here is a well-formed Lispy term that <span>read</span> has no problem with: <span>(</span><span>lambda</span> <span>1</span><span>)</span>. That is, however, a <span>syntax</span> error in most Lisps: a determination made by the parser, not the reader. Of course, nothing prevents us from creating a new language where that term has some meaning.<span>Indeed, <a href="https://github.com/shriram/lambda-n">I now have</a>.</span> That language’s parser would be responsible for making sense out of the pieces.</p></li><li><p>People sometimes believe you can only have macros if you have a bicameral syntax. This isn’t true: all you need is a way to represent code, because macros transform code to code. But as more languages have realized the benefits of having macros, some have added <span>procedural</span> macros (an idea that dates back decades in Lisp lore). Bicameral syntaxes just provide a gateway to gloriously rich macro systems, because we’ve learned that the well-formedness layer is an especially good layer atop which to build macros.</p></li></ol><section class="SsectionLevel2" id="section 7" morss_own_score="6.797833935018051" morss_score="32.33456297174709"><h2>7 <a href="https://parentheticallyspeaking.org/articles/bicameral-not-homoiconic/#(part._.What_.About_.Other_.Languages_)" title="Link to here">🔗</a> </h2><p>I want to end with some forward-looking comments.</p><p>One of my frequent sources of amusement—</p><p>I would like to suggest another path forward: start with a bicameral syntax. Quickly get to the point where you can think about <span>semantics</span>. What does your language <span>do</span>? How does one reason about programs? How does one run them? Do all the hard and interesting and important parts first.</p><p>But, you argue, “Now I have a bicameral syntax! Nobody will want to program in it!” And that may be true. But I want you to consider the following perspective:</p><blockquote><p>Syntax is a view.</p></blockquote><p>One of the enduring lessons we’ve learned from software design is the model-view separation: that is, there are often many useful ways to view the same thing, some of which we haven’t even dreamt up yet, so it’s wise to separate an object from how we view it (and coordinate the different views). This principle seems to virtually never be applied to programs, but it should! We should view the <span>abstract</span> syntax as the model—<span>every</span> syntax as a view on it.</p><p>So what you should really do is define an abstract syntax, and layer a light bicameral concrete syntax on top of it. Then build all the other parts. And then, think about what views you want to provide. Some people may be happy with the bicameral syntax. Others may want a more traditional infix syntax. Some may want braces, some may want significant whitespace. Some users may even want to use blocks—<span>This is not to say syntax is not hard; it’s actually harder than most people think, because it requires a delicate interplay between mathematics and human factors—</span> Both <a href="https://www.hashcollision.org/brainfudge/">F*dging up a Racket</a> and, in much more depth, <a href="https://beautifulracket.com/">Beautiful Racket</a> illustrate this principle practically and beautifully.</p><p>This perspective also gives you a useful artifact: a bicameral syntax that is a very nice target for programs that need to generate programs in your language. This is no longer a new idea, so you don’t have to feel radical: formats like SMT-LIB and WebAssembly text format are s-expressions for a reason. Our <a href="https://forge-fm.org/">Forge</a> tool supports both a syntax based on <a href="https://alloytools.org/">Alloy</a> and one in s-expressions, the former for (most) people to use, the latter a target to tools that use Forge as a back-end.</p><p>In short, I hope this inspires a new vision of syntax design. Bicamerality is the best intermediate language we’ve come up with; it’s driven by both theoretical elegance and practical experience. For some, the bicameral syntax is also a lovely source language, but it should be just one of many views onto the core abstract syntax. Tools will become more reusable and, at the same time, the syntax wars can end. We can find peace, joy, and happiness. It is not a coincidence that a pair of parentheses looks like an embrace.</p></section></section>https://parentheticallyspeaking.org/articles/pls-nature/<section class="SsectionLevel1" id="section 0" morss_own_score="6.681576952236543" morss_score="83.95715204567544"><h1>Objects in Nature<a href="https://parentheticallyspeaking.org/articles/pls-nature/#(part._pls-are-natural-objects)" title="Link to here">🔗</a> </h1><p>In the early 1990s, the programming languages research community was in an optimistic mood. In the recent past, two of its paradigmatic languages—</p><p>What went wrong?</p><blockquote><div>If you’re a working programmer without a theoretical background, you might wonder why a formal semantics matters at all. It’s actually for reasons you can understand easily. When you write programs against code that someone else wrote, you like having an interface, or <span>API</span>, to program against. It mediates your conversation with the remote code, and anchors conversations about whom to blame if something doesn’t work as expected.</div><div>The formal semantics of a language does exactly the same thing. The language itself is the “remote code” you’re programming against. What it does should be pinned down as precisely as possible—</div><div>The semantics isn’t just an interface for the user of a language. It’s also a crucial interface for tool authors, who must (also) otherwise guess at the behavior of the language. If you want an example of how even the relatively simple act of a variable rename refactoring can go wrong, see Appendix 2 of our <a href="https://cs.brown.edu/~sk/Publications/Papers/Published/pmmwplck-python-full-monty/">Python semantics</a>. A semantics doesn’t guarantee those kinds of errors won’t occur, but its absence makes them far more likely to.</div></blockquote><p>For many researchers, it’s a given that programming languages are <span>mathematical</span> objects. This is a natural and attractive view. Languages are formal objects, after all; they are therefore amenable to codification by everything from logic to topology and more. (Formal) Specification is a natural consequence of this worldview.</p><p>The world, however, is full of programming languages that do not fit this model.<span>Some may even have been created by programming language semanticists, which is worth pondering.</span> Created by the ostensibly unwashed, they rudely announce their arrival with nothing more than an implementation. People pick them up, find them useful, do worthwhile things with them, and a million lines later, the next big “scripting language” is born. Let’s call these <span>informal</span> languages.</p><p>Informal languages are, of course, also amenable to formal specification. However, a crucial difference governs these two types of languages. Suppose we observe a difference between what the specification says and what the implementation does. In the case of Standard ML, for instance, one can approach the implementor, walk through the reasoning in the specification, and explain why the implementation is wrong. If the implementor agrees with your reasoning, no matter how unhappy this makes them, they must admit to and eventually fix their implementation.</p><p>The implementor of an informal language faces no such constraint. Faced with a mismatch between an ostensible specification and their implementation, they are free to simply laugh, question the specification’s parentage, and exit stage right. The specification can <span>at best</span> track what “the language is doing”, not really dictate its behavior.</p><div>Specification still serves a role. It can: </div><ul><li><p>Shed light on what is happening inside a large and otherwise opaque implementation.</p></li><li><p>Point out complex designs that would warrant being simplified.</p></li><li><p>Highlight design aspects that are prone to cause programmer error, security violations, and so on.</p></li><li><p>Serve all the other uses of a specification, such as serving as a basis for building tools.</p></li></ul><div>To do all these things <span>usefully</span>, however, the specification must take significant steps to show its conformance to the reality of the informal language, such as by running the same test suites as the implementations.</div><p>An informal language, then, is much more like an object found in nature:</p><p><img src="https://parentheticallyspeaking.org/articles/pls-nature/rock.jpg"></p><p>We can push at it, poke it, and prod it, and hope that it will yield its secrets. But we can never be certain—</p><p>That doesn’t mean we can’t approach the problem systematically. Geologists, confronted with a rock, don’t flail helplessly. In high-school chemistry, I was taught to approach unknown substances with the <span>SCODS</span> test: check for its state, color, odor, density, and solubility.<span>They never included a letter for “taste”, a reflection perhaps more of their aspiration than of the reality in a high school chemistry lab.</span> That is, we identify some of dimensions of classification, and proceed along the principal axes.</p><p>We have these axes for programming languages, too. We can talk about their scope rules, their evaluation semantics, their type system, and so on. Indeed, because so much of a programmer’s career will be spent confronting informal languages and having to rapidly make sense out of them, I’ve long felt that how we <span>teach</span> programming languages should <a href="https://cs.brown.edu/~sk/Publications/Papers/Published/sk-teach-pl-post-linnaean/">also be divided along these dimensions</a>.</p><p>The problem of informal languages will not go away, so long as a dedicated amateur can scare up a new language’s implementation. Indeed, the size of our informal language space grows ever-bigger, and vastly so, than that of mathematical languages. In 2015, I made this slide:</p><p><img src="https://parentheticallyspeaking.org/articles/pls-nature/stack.png"></p><p>It shows the stack atop which a typical client-side Web program of the day resided. What it actually shows is something much more subtle and important:</p><p><span>Programmers do not program in “languages”.</span></p><p>Rather, they program in some complex combination of languages, libraries, frameworks (which can impose their own operational behavior—</p><p>For illustrative examples of what such semantics might look like, see our work on the <a href="https://cs.brown.edu/~sk/Publications/Papers/Published/lckqk-model-reason-dom-events/">operational semantics of the <span>DOM</span></a> (it’s a giant control operator, y’all!), and <a href="https://cs.brown.edu/~sk/Publications/Papers/Published/lelk-types-jquery-programs/">the type structure of jQuery</a>. But these are just a tiny sliver of a tiny sliver. How do we make real progress up the mountain and keep our position there as it keeps thrusting further out of the ground?</p><p>We can’t expect the date-picker library’s author to also be a semanticist. But we shouldn’t therefore resignedly conclude that we can never get there. Rather, we should acknowledge that there are useful divisions of labor. Instead of scolding informal language designers for their practices, semanticists need to find methods to bridge that gap, keeping in mind:</p><blockquote><p><span>One can’t proceed from the informal to the formal by formal means.<br><span>—</span></span></p></blockquote><div>Whatever we propose needs to be: </div><ul><li><p>Reasonable (in terms of skill) for the implementor to produce.</p></li><li><p>Useful for them to produce.</p></li><li><p>Useful for us to consume and work with.</p></li></ul><div>One especially good intermediate proxy is a test suite of some sort. Tests don’t always get the respect they deserve, but they too are a form of specification. I like to call them “specifications from below”, precisely defining what should happen in individual cases, whereas the typical formal specification is “specification from above”, defining what happens across a family of cases. Ultimately, of course, we need specifications “from above”, but it’s worth noting that specifications “from below” are both useful to developers and something they are skilled at producing. The recent trend in languages of producing “confirmance suites” or “litmus tests” is especially promising in this regard. (Our work on formalizing the <a href="https://cs.brown.edu/~sk/Publications/Papers/Published/pclpk-s5-semantics/">strict mode of of ECMAScript 5.1</a>, for instance, made use of the ECMAScript conformance suite.)</div><p>How we use them remains a little bit of an open question. The most obvious use is to test our semantics: what <a href="https://ccs.neu.edu/~arjunguha/main/home/">Arjun Guha</a> and I, to perhaps the horror of some, called a <span>tested semantics</span>. But we might also be able to generalize these tests, from “below” to “above”, i.e., it’s a synthesis problem. This requires some structure to produce a semantics that is also meaningful. Our paper on <a href="https://cs.brown.edu/~sk/Publications/Papers/Published/kle-next-700-semantics//">The Next 700 Semantics</a> describes some of the contours for this line of work to consider.</p></section>https://parentheticallyspeaking.org/articles/pedagogic-ide/<section class="SsectionLevel1" id="section 0" morss_own_score="6.35966735966736" morss_score="39.73874899784852"><h1><a href="https://parentheticallyspeaking.org/articles/pedagogic-ide/#(part._pedagogic-ide)" title="Link to here">🔗</a> </h1><p>I have been thinking about the design, technology, and human factors aspects of programming environments—<span>IDE</span>s, for “integrated development environments”—</p><h2>1 <a href="https://parentheticallyspeaking.org/articles/pedagogic-ide/#(part._.How_to_.Read_.This_.Article)" title="Link to here">🔗</a> </h2><div>This article is three very different things, that sit together a little awkwardly: </div><ol><li><p>a historical retrospective,</p></li><li><p>a list of criteria, and</p></li><li><p>a proposal for progress.</p></li></ol><div>Indeed, it is written roughly in that order, starting with our early design of DrRacket, proceeding with newer lessons that all offer useful criteria, and culminating in a proposal for what really distinguishes pedagogic settings.</div><p>As you read, it’s also worth keeping in mind that “pedagogic” is not a hard criterion that admits some <span>IDE</span>s always and others never. The bullet items below provide several characteristics that pedagogic <span>IDE</span> should have, and many have some subset of them, even ones not intentionally designed for use with students. Thus, it is perhaps more helpful to think about pedagogy as a <span>mode</span>—<span>IDE</span> is being configured for use at a particular moment—</p><p>Thanks to the many people <a href="https://twitter.com/ShriramKMurthi/status/1341907464162332672">on Twitter</a> who gave feedback, especially Jonathan Aldrich.</p><h2>2 <a href="https://parentheticallyspeaking.org/articles/pedagogic-ide/#(part._.At_the_.Beginning)" title="Link to here">🔗</a> </h2><p>We began the <a href="https://www.drracket.org/">DrRacket</a> project (then called DrScheme) in 1995 on the premise that we wanted to build a <span>pedagogic</span> <span>IDE</span>. Our initial goals were set by our context: students learning to program in Scheme inside Emacs. Each such institution had its own set of idiosyncratic Emacs key-bindings that students were forced to memorize, while also being plunged into the complexity of an editor vastly more sophisticated than anything they had used before, where any odd key combination could drop them into a confusing state from which recovery often needed expert help.<span>No, this is not an Emacs rant. For the record, I still use Emacs. In fact, this article was written using Emacs.</span> It was hardly student-friendly for all but the most adventurous (who, of course, loved it).</p><p>At the same time, this is when the US’s AP Computer Science curriculum was shoving C++ down the throats of schools. As a result, many students were entering college having seen a sophisticated graphical <span>IDE</span> like Visual C++. On the one hand, these set an expectation amongst students that an <span>IDE</span> would be a rich graphical environment that looked like a native application; its absence made education feel inauthentic. On the other hand, the number of buttons and options in such <span>IDE</span>s were problematic. Many students felt overwhelmed; a few (probably the same ones who loved discovering the recesses of Emacs) clicked away at random, losing sight of fundamental learning.</p><div>Thus, at the very outset, we had three goals: </div><ul><li><p>Make a reasonable, modern, native-looking application.</p></li><li><p>Make a stand-alone application where we can control the experience, rather than an island surrounded by a sea of dragons.</p></li><li><p>Minimize distraction, confusion, and unnecessary (especially undesirable) choice.</p></li></ul><div>We have since grown comfortable with applications being delivered through the Web, so Web-based <span>IDE</span>s are now a reasonable alternative to that native application, and indeed confer many benefits that the native application does not. However, these conceptual rules remain important.</div><h2>3 <a href="https://parentheticallyspeaking.org/articles/pedagogic-ide/#(part._.More_.Insights)" title="Link to here">🔗</a> </h2><div>As we continued to build DrRacket, a few more rules became clear. We have documented them and their justification extensively elsewhere (such as <a href="https://cs.brown.edu/~sk/Publications/Papers/Published/fffkf-drscheme-journal/">this paper</a> and <a href="https://cs.brown.edu/~sk/Publications/Papers/Published/fffkbmt-programmable-prog-lang/">this one</a>), so I’ll just summarize them here: </div><ul><li><p>Languages evolve by accruing complexity, which can create dangerous reefs on which students can founder. We need principled, teaching-friendly sub-languages that eliminate accidental complexity.<span>Even if a language is designed from scratch to avoid this problem, it can still contain different levels of complexity.</span></p></li><li><p>Just as a textbook does not plunge students into a whole language at once but rather builds it up incrementally, <span>IDE</span>s should introduce the language incrementally, matching a book’s needs and supporting a learning progression.</p></li><li><p>Errors matter! Error messages should be carefully written to be friendly and helpful to students, whose needs may be different from those of a developer.</p></li><li><p>Sub-languages must be epistemically closed, with errors inside this closure. Concretely, error messages should never use vocabulary or concepts beyond what has been introduced up to that point in the curriculum.</p></li></ul><p>These principles drove the development of DrRacket. Furthermore, <a href="https://racket-lang.org/">Racket</a> created <a href="https://cs.brown.edu/~sk/Publications/Papers/Published/ffkf-mred/">linguistic</a> <a href="https://cs.brown.edu/~sk/Publications/Papers/Published/fffkbmt-programmable-prog-lang/">abstractions</a> that embodied these ideas. This enabled several textbooks to map their own learning progressions to corresponding sub-languages in DrRacket, giving their student users the same benefits that users of <a href="https://htdp.org/">How to Design Programs</a> enjoyed.</p><h2>4 <a href="https://parentheticallyspeaking.org/articles/pedagogic-ide/#(part._.More_.About_.Feedback)" title="Link to here">🔗</a> </h2><p>We weren’t done with error messages (and <span>IDE</span> feedback more generally). Starting in 2010, <a href="https://gmarceau.qc.ca/">Guillaume Marceau</a>, <a href="https://cs.brown.edu/~kfisler/">Kathi Fisler</a>, and I began to investigate the error messages of DrRacket using the methods of <span>HCI</span>. What <a href="https://cs.brown.edu/~sk/Publications/Papers/Published/mfk-measur-effect-error-msg-novice-sigcse/">we found</a> was deeply disturbing: that the errors often were not helping students fix their problems.</p><div>Indeed, <a href="https://cs.brown.edu/~sk/Publications/Papers/Published/mfk-mind-lang-novice-inter-error-msg/">we also found</a> that even the vocabulary used in messages was difficult for students. For instance, we had carefully distinguished between concepts like “operator”, “constructor”, and “predicate”. But for students who had not yet picked up those distinctions, these all looked like gobbledygook; the only term they were familiar with was “function”. This necessitated <span>removing</span> these careful distinctions to make the messages more decipherable and hence actionable. We also noticed that instructors often used vocabulary different from that of the <span>IDE</span>; libraries also created their own ontology or used their own style that contradicted the <span>IDE</span>. In short, </div><ul><li><p><span>IDE</span> feedback lives in an ecosystem consisting of the programming language, books, third-party libraries, educators, and more. All of these need to be in harmony, and require style guides to facilitate agreement.</p></li></ul><h2>5 <a href="https://parentheticallyspeaking.org/articles/pedagogic-ide/#(part._.Ground_.Truth)" title="Link to here">🔗</a> </h2><p>Over the past few years, I’ve come to realize there is another critical aspect to pedagogic <span>IDE</span>s that truly distinguishes them from a conventional <span>IDE</span> designed for a developer. It’s that a pedagogic <span>IDE</span> has <span>ground truth</span>. I’ve been pursuing this under various guises for some years now, but only in the past two years have these pursuits coalesced into a clear thesis.</p><p>Here’s what I mean by ground truth. In almost every pedagogic setting, we are asking students to create <span>something we have already done</span>. Therefore, we not only have full knowledge of the answer, we’ve even already created instances of the solutions we are asking them to build. That is, we are trying to bring students to the same level of achievement that we already have.</p><p>In a conventional programming setting, such as in industry, programmers do not re-build perfect replicas of existing systems. If they’re re-implementing a system, often it’s with an eye to at least improving it, and usually to ultimately changing it. In the very rare cases that they want to identically reproduce a system, it’s usually for intellectual property reasons, and thus done with various safeguards against communication. In general, though, the thing they are trying to build doesn’t already exist (which is why they’re building it—</p><p>This is the opposite of what we do in education. In education, it is utterly standard for a hundred students to all be striving, independently, to perfectly reproduce something we have already done.<span>Indeed, great effort goes into making sure these students don’t merely pawn off as their own what other students have done.</span> There are solid educational reasons for this. The fact that we have done all this already, and can often point to our work as exemplary, gives us the <span>ground truth</span> that conventional programming lacks. My thesis is that:</p><p><span>This ground truth can and should be </span><span> exploited to improve student learning.</span></p><h2>6 <a href="https://parentheticallyspeaking.org/articles/pedagogic-ide/#(part._.How_.Can_.We_.Use_.Ground_.Truth_)" title="Link to here">🔗</a> </h2><p>In a way, numerous educators, for decades, have been using ground truth: by giving students a test suite against which to run their programs. I find this practice odious for several reasons:<span>If you are going to do it anyway, at least avoid the <a href="https://cs.brown.edu/~sk/Publications/Papers/Published/wkf-who-tests-testers/">perils we’ve identified</a>.</span> It promotes “passing the instructor’s suite” as the most important trait a program should satisfy (whereas, often, it is one of the least important). It fails to teach students to think about correctness for themselves, treating it as an outsourced activity. It often encourages a mentality of “keep tweaking and submitting until you pass”, which as a programming practice is both utterly unauthentic and arguably dangerous. (Adding rate limits is a symptom of a problem with the pedagogy, not a solution.) More subtly, and perhaps worse, it robs students of important <a href="https://blog.brownplt.org/2024/01/01/examplar.html">stimuli for problem understanding</a>. But most of all, this is primarily a means of <span>assessment</span>, not of <span>instruction</span>.</p><div>Nevertheless, we can recognize in this widely-used practice the germ of this idea, but we should turn it into a student aid, and we need to generalize it. Why has it not already been widely generalized? I would argue for two reasons, one pedagogic and one technical: </div><ul><li><p>We don’t ask students to produce a broad enough range of artifacts.</p></li><li><p>Comparing artifacts is hard from a technical perspective. Relatedly, giving actionable feedback is hard both technically and from a human factors perspective.</p></li></ul><section class="SsectionLevel2" id="section 7" morss_own_score="6.759213759213759" morss_score="37.02318891449326"><h2>7 <a href="https://parentheticallyspeaking.org/articles/pedagogic-ide/#(part._.Multiple_.Artifacts)" title="Link to here">🔗</a> </h2><div><a href="https://htdp.org/">How to Design Programs</a> is perhaps the canonical example of a programming pedagogy that asks students to produce (a) multiple artifacts, that are (b) interrelated, and are in a (c) progression that matches progress through problem-solving. Concretely, students are asked to produce </div><ul><li><p>data definitions</p></li><li><p>a purpose statement</p></li><li><p>a function signature</p></li><li><p>examples of function use</p></li><li><p>a function template</p></li><li><p>the function body</p></li><li><p>tests of the function</p></li></ul><div>The nice thing about having multiple artifacts from different stages of development is that: </div><ul><li><p>We can give feedback early.</p></li><li><p>We can correct problems when it doesn’t cost much to fix them. (Once a student has fully implemented their system, giving feedback on failing tests will invariably only produce minor tweaks in the program, never large-scale architectural changes.)</p></li><li><p>We can give different kinds of feedback, some of which will be better appreciated by some students and others better by others.</p></li><li><p>We can make the desolate progression from a blank page to a fully-working program a more rich, textured interaction between student and (otherwise foreboding and hostile) tool.</p></li></ul><div>Imagine that for each of the artifacts above, we have our own ground truth versions (which presumably we have written while developing the problem). We can, in principle, compare </div><ul><li><p>our data definition against theirs</p></li><li><p>our function signature against theirs</p></li><li><p>our examples against theirs</p></li></ul><div>and so on. But we can also compare each of these artifacts against <span>other kinds</span> of artifacts. Running their program against our tests is conventional practice, but we have many more choices: </div><ul><li><p>our data against their data definition</p></li><li><p>our examples against their function signature</p></li><li><p>our function against their examples</p></li></ul><div>and so on and on—</div><p>In fact, we can go farther. We don’t only have to implement <span>positive</span> instances of these artifacts: we can also implement <span>negative</span> instances (i.e., non-solutions). Using a combination of known-common mistakes and just random mutation, we can produce <span>incorrect</span> versions of all these artifacts, which have their own uses. Incorrect programs are routinely used to measure the quality of a test suite (<a href="https://en.wikipedia.org/wiki/Mutation_testing">mutation testing</a>). We can do that, and more, comparing positive and negative instances of student artifacts with an eye towards making the programming process a conversation with a knowledgeable companion.</p></section><h2>8 <a href="https://parentheticallyspeaking.org/articles/pedagogic-ide/#(part._.Comparison_is_.Hard)" title="Link to here">🔗</a> </h2><p>We run tests against programs because we know how to do it, and the output is easy to explain. An instructor may <span>choose</span> to hide output (e.g., only reporting the number of tests that passed or failed), but if they chose to provide more information, it’s quite easy to say “on the input <span>3</span>, your function produced <span>8</span> instead of <span>9</span>” and a student would not have much trouble understanding this utterance (even if they can’t explain why they produced <span>8</span> or why they were supposed to produce <span>9</span>).</p><p>Unfortunately, that is not only the easiest case, it may be the only easy one. Comparing two purpose statements is <span>AI</span>-complete since it requires handling natural language; and while the language here may be relatively structured (and poorly-structured statements can be rejected summarily), ensuring very high precision and recall, and giving feedback that is understandable by a computing novice, is very hard. Other pairs sit somewhere in-between. For instance, a long line of research has studied how to compare two programs. But we need the output to be actionable by a student. A program dependency graph may be semantically meaningful, but a novice won’t be able to make sense out of it.</p><h2>9 <a href="https://parentheticallyspeaking.org/articles/pedagogic-ide/#(part._.Progress)" title="Link to here">🔗</a> </h2><p>With several collaborators, I’ve been making progress towards realizing this vision for several years now. For instance, <a href="https://blog.brownplt.org/2024/01/01/examplar.html">Examplar</a>, <a href="https://cs.brown.edu/~sk/Publications/Papers/Published/ghlrfk-design-alt-data-org/">D4</a>, and <a href="https://forge-fm.org/">Forge</a> are all direct implementations of different parts of this idea. Forge, which <a href="https://cs.brown.edu/people/tbn/">Tim Nelson</a> spearheads, is a particularly good illustration of this. It tackles a problem—<a href="https://cs.brown.edu/~sk/Publications/Papers/Published/kn-human-formal-methods/">brief paper</a> to accompany a keynote talk says a little more about this (see section 3.2).</p><p>Obviously, all this only scratches the surface. The ideas are robust, but it takes a lot of careful work on semantics and human factors, and we need tooling to link the former with the latter. That said, to me there’s something oddly exciting about this line of research: I’ve been working in this space for 25 years, but each time there’s a fresh level of insight, it feels like I’m just getting started!</p><h2>10 <a href="https://parentheticallyspeaking.org/articles/pedagogic-ide/#(part._.Credits)" title="Link to here">🔗</a> </h2><p>Even though this is written in the first person, all the ideas here grew out of collaborations with amazing people on the <a href="https://www.drracket.org/">DrRacket</a>, <a href="https://www.wescheme.org/">WeScheme</a>, and <a href="https://www.pyret.org/">Pyret</a> teams. They include: <a href="https://felleisen.org/matthias/">Matthias Felleisen</a>, <a href="https://users.cs.northwestern.edu/~robby/">Robby Findler</a>, <a href="https://www.cs.utah.edu/~mflatt/">Matthew Flatt</a>, <a href="https://cs.brown.edu/~kfisler/">Kathi Fisler</a>, <a href="https://gmarceau.qc.ca/">Guillaume Marceau</a>, <a href="https://www.hashcollision.org/">Danny Yoo</a>, Emmanuel Schanzer, <a href="https://www.khoury.northeastern.edu/people/benjamin-lerner/">Ben Lerner</a>, <a href="https://jpolitz.github.io/">Joe Gibbs Politz</a>, <a href="https://jack.wrenn.fyi/">Jack Wrenn</a>, <a href="https://cs.brown.edu/people/tbn/">Tim Nelson</a>.</p></section>https://parentheticallyspeaking.org/articles/first-language-wrong-question/<section class="SsectionLevel1" id="section 0" morss_own_score="6.404617253948968" morss_score="39.796283920615636"><h1>Should I Teach First?<a href="https://parentheticallyspeaking.org/articles/first-language-wrong-question/#(part._first-lang-wrong-q)" title="Link to here">🔗</a> </h1><p>“Which programming language should I teach first?” is the least productive question to ask in computer science. There’s a good reason it’s unproductive: it’s the wrong question to ask. The reason computer science’s endless “language wars” feel pointless is that they’re a symptom of this problem. Here’s why.</p><div>Curricula are never designed in isolation. All curricula, for anything, have to begin by considering the following: </div><ul><li><p>First: goals. These must obviously begin with learning objectives. However, they must go a lot farther: e.g., “students must eventually get jobs”. But even “jobs” is not some monolith: even within the same discipline, the expectations of a university that places students primarily in the small companies in its local area are completely different from those of one that intends to place students at world-class companies across the globe. (I’ve studied, worked at, visited, and helped universities at numerous points, and indeed both ends, of this spectrum. The differences are night and day.)</p></li><li><p>Second: constraints. Constraints vary across both space (different places) and time (different years). The constraints can include: the needs of the rest of the university; whether the department is in a College of Engineering or College of Arts and Sciences; whether the department is accredited; how many majors the department offers; how many <span>competing</span> majors are offered by other departments on campus; and so on.</p><p>There are also unwritten, unacknowledged, but very real constraints like how resistant to change the faculty are. And there can be even subtler constraints: I remember a well-known computer science professor arguing with me about the importance of teaching C in the first semester (she was firmly in favor). After a few rounds, she acknowledged that her main consideration was actually that students be prepared to work on her lab’s research projects, which were (then) all implemented in C. Strange as this may be, you can’t make progress until this has been articulated: until then, to use the “language wars” metaphor, you’re effectively fighting a proxy war.</p></li></ul><div>Curriculum design is an optimization problem. Without stating goals, we don’t even know what we’re solving for. Without stating constraints, we don’t know what the feasible set of solutions is. Thus, until we’ve articulated both, we can’t even <span>begin</span> a meaningful conversation.</div><p>Programming languages are a solution-space artifact: they fall into the feasible set. You don’t <span>start</span> with them, you <span>end</span> with them, relative to everything else. So starting with the “which programming language” question is guaranteed to lead to talking at cross-purposes.</p><p>A basic problem in computing education is that we don’t even have a vocabulary for what we’re talking about. As a result, we reduce everything to a language, which is not necessary, sufficient, or even useful. As an example, for a long time, educators found curricula like <a href="https://en.wikipedia.org/wiki/Structure_and_Interpretation_of_Computer_Programs">Structure and Interpretation of Computer Programs</a> (<span>SICP</span>) hard. (Now, they’ve just stopped talking about it.) This got translated to “Scheme is hard”, because people could only see things through the overly simplistic lens of the programming language. What they missed is that <span>SICP</span> and other curricula, typically coming out of functional programming, had gone well past the “rubbing two rocks to get sparks” stage to, for their time, the “igniting boosters” stage.</p><p>The other problem we have in computing edcuation is that we don’t think enough about how we can relax the constraints, future-proof the goals, widen the space of methods, etc. So we go from one blub language to another per decade: Pascal, C, C++, Java, Python… Here is my highly scientific summary of the progress we’ve consequently made in computing education:</p><blockquote><table><tr><td><p><span>Decade</span></p></td><td><p><span>Dominant Language</span></p></td><td><p><span>Dominant Data Structure</span></p></td></tr><tr><td><p>1970s</p></td><td><p>Pascal</p></td><td><p>arrays</p></td></tr><tr><td><p>1980s</p></td><td><p>C</p></td><td><p>arrays</p></td></tr><tr><td><p>1990s</p></td><td><p>C++</p></td><td><p>arrays</p></td></tr><tr><td><p>2000–2015</p></td><td><p>Java</p></td><td><p>ArrayList</p></td></tr><tr><td><p>2015–now</p></td><td><p>Python</p></td><td><p>associative arrays</p></td></tr></table></blockquote><p>Whatever languages make easy become the default and determine a lot of other things. What languages make hard get ignored for many reasons. This is why so many of our curricula today look not that different from the curricula from the mid-1980s onward, once Pascal really consolidated itself in curricula.</p><p>A lot of people reading this are likely to be computing people who are sometimes asked to help out in schools. If you find yourself in this situation, I beg you, please watch at least until 8m30s into this talk: <a href="https://www.youtube.com/watch?v=5c0BvOlR5gs">Curriculum Design as an Engineering Problem</a>. You’ll get it. It’s designed for you!</p><p>To be clear, I am not a disinterested party. I’ve worked on multiple programming languages, <a href="https://racket-lang.org/">Racket</a> and <a href="https://www.pyret.org/">Pyret</a>, and two books, <a href="https://htdp.org/">How to Design Programs</a> and <a href="https://dcic-world.org/">A Data-Centric Introduction to Computing</a>, designed for introductory programming education. These are opinionated languages and books. To a good extent, the languages and books are co-designed, so they present unified, coherent worldview. Naturally, I encourage you to check them out! You may also find this talk interesting: <a href="https://youtu.be/HwPM0xMdiNU?si=-yEIW6tFGEt3EjLX">A Data-Centric Introduction to Computing</a>.</p></section>https://parentheticallyspeaking.org/articles/us-cs-phd-faq/<section class="SsectionLevel1" id="section 0" morss_own_score="6.366494498091175" morss_score="39.00451359978622"><h1><a href="https://parentheticallyspeaking.org/articles/us-cs-phd-faq/#(part._us-cs-phd-faq)" title="Link to here">🔗</a> </h1><p>(Thanks to: Amy Ko, Ben Shapiro, Chris Bohn, Florian Tramèr, Geoff Langdale, Gopal Kotecha, Kristin Stephens-Martinez, Michael Ekstrand, Michael Greenberg, mikebonnell, Molly Jane Nicholas, Paolo G. Giarrusso, Pierce Darragh, Sam Tobin-Hochstadt, Sreepathi Pai, Talia Ringer, Thomas Dickerson, Titus Barik.)</p><blockquote><p>If you prefer content in video form, you can watch <a href="https://www.youtube.com/watch?v=IprN9fPV2LI">my video</a> from October 31, 2021. Unlike this document, however, it won’t be updated. I would prefer this document over that video.</p></blockquote><p>The following article is written from a purely personal perspective. As of this writing (in 2021), I have read thousands of application folders and participated heavily in admissions. Still, my opinion is heavily influenced by my own environments, experiences, and beliefs. Therefore, these opinions should not be viewed as universal, nor will following them definitely get you into a PhD program of your choice. My main goal is to fill the gap of information, and dispel the significant misinformation, that hurts applicants.</p><p>Two things, in particular, can significantly alter some of these answers.</p><p>First, there are (to my mind) three to four major “tiers” of universities. There’s the extremely-competitive tier (places like MIT, Stanford, Berkeley, CMU, and perhaps some others) where nothing short of having an absolutely outstanding application will suffice. There’s the highly-competitive tier (which includes places like Brown) where the majority of applicants do not get admitted, but you can get in by having a strong, but not necessarily absolutely outstanding, application. There are competitive places where being a solid applicant will suffice, and in particular, professors in some areas (those that don’t attract very many good applicants) may be willing to admit students who have notable weaknesses. And finally there are probably some not-very-competitive places where many students can get in. To get into the extremely-competitive tier, it’s somewhat obvious you need an outstanding application. I think there’s much more ambiguity about the next two tiers, so that’s where I’m focusing my answers: especially at the highly-competitive places.</p><p>Second, at this time, the AI-related fields (such as machine learning) seem to be absolutely flooded with applicants. I think the simplest way to understand it is that faculty in this area are admitting as if they are at an institution one tier up. (The students from Brown I see going to the extremely-competitive tier in AI-related fields seem to be just “off the charts”.) So in some sense, if you’re applying in those areas, what follows still applies: you just have to perform that shift in your head.</p><h2>1 <a href="https://parentheticallyspeaking.org/articles/us-cs-phd-faq/#(part._.Context)" title="Link to here">🔗</a> </h2><h3>1.1 <a href="https://parentheticallyspeaking.org/articles/us-cs-phd-faq/#(part._.Are_you_providing_standardized_information_)" title="Link to here">🔗</a> </h3><p>There is no standardized information. It’s important to understand that the US system is almost completely decentralized.</p><p>There are some common rules imposed by government agencies on aspects like funding and visas. But <span>everything</span> else is delegated to the universities, who in turn may delegate things further to individual departments.</p><p>Thus, almost any sufficiently unambiguous statement will cough up several counter-examples. I’m doing my best to abstract; in some cases, I am stating a personal opinion (which I will make clear).</p><h3>1.2 <a href="https://parentheticallyspeaking.org/articles/us-cs-phd-faq/#(part._.Why_do_you_keep_using_the_word__school___.I_finished_school_a_long_time_ago_)" title="Link to here">🔗</a> </h3><p>The great thing about English is that there are so many Englishes to choose from. In many parts of the world, “school” is a place where you (typically) finish your education at age 16 or 18. In America, “school” is any place where you get schooling, i.e., an education. Thus you can have “middle school” but also “trade school” and “graduate school”.</p><h3>1.3 <a href="https://parentheticallyspeaking.org/articles/us-cs-phd-faq/#(part._.What_s_the_difference_between_a_master_s_and_a_.Ph.D_)" title="Link to here">🔗</a> </h3><p>A master’s degree has a clear end in sight: usually you take about eight courses over a period of one to two years.</p><p>A PhD does not have a clear end in sight: you only graduate if you complete and successfully defend a dissertation. More below.</p><p>The master’s is typically a <span>professional</span> degree: it’s meant to prepare you to work in industry. Some master’s programs have a research option (or perhaps even a research requirement), but the research here is usually rather modest because the student will not stay indefinitely.</p><p>A PhD’s main job is <span>research</span> preparation. That takes a while. The goal is that when you graduate, you have the skills to conceive an execute a research project by yourself.</p><p>A master’s is typically not funded (see why: <a href="https://cs.brown.edu/~sk/Memos/Funding-CS-Grad-School/">How CS Master’s Funding Works</a>).</p><h3>1.4 <a href="https://parentheticallyspeaking.org/articles/us-cs-phd-faq/#(part._.Should_.I_apply_for_a_.Ph.D_directly_)" title="Link to here">🔗</a> </h3><p>In many countries, you are expected to have a master’s before you apply for a PhD. Not so in the USA: you can apply directly out of a bachelor’s degree. However, that assumes a four-year bachelor’s degree (which is the standard in the USA). In some countries the bachelor’s is only three years long. It is not standard to transition from that to a US PhD program; in fact, some institutions may even require you to have finished more than three years of undergraduate study.</p><div>That said, even if you have a four-year bachelor’s, some reasons to apply for a master’s first are: </div><ul><li><p>You have a weak background in computer science and want more preparation.</p></li><li><p>You aren’t sure whether you will like advanced study, and want to test it out first.</p></li><li><p>You want to get a taste of research. (Make sure you apply to a master’s program that has a research track!)</p></li><li><p>You want to strengthen your application to get into a better program.</p></li></ul><div>These are all good reasons to get a master’s first.</div><p>One thing a master’s won’t help with <span>much</span> is reducing time spent in your PhD, unless you stay at the same institution. When you switch institutions the requirements change, you have to forge new relationships, etc. So sometimes, a master’s followed by a PhD elsewhere can take just as long and maybe even longer than a PhD at the latter institution from the beginning. Therefore, make sure you apply for a master’s for the right reason.</p><p>One thing to note is that you will usually get a master’s along the way to your PhD, in return for meeting some requirements. Of course, to get this master’s you will have to fill out some routine paperwork. I forgot to, so I didn’t get one…</p><h3>1.5 <a href="https://parentheticallyspeaking.org/articles/us-cs-phd-faq/#(part._.Do_.I_have_to_be_22_years_old_)" title="Link to here">🔗</a> </h3><p>No, you can even be <a href="https://www.brown.edu/news/2021-11-12/steiner">89 years old</a>.</p><p>Some people spend time in industry or doing other things before starting a PhD. Some people may also be “grown up” and start later in life. Of course, if you have a family to support, you have to think about how you can do that on a graduate student stipend (somewhat unlikely; you may need a partner who is better paid).</p><p>If you have spent a considerable time away from academia (e.g., a long stint in industry), it’s especially important to follow advice in this document on your statement of purpose, etc. At some point your course grades become less and less meaningful, and other things you have done become a stand-in for what you are capable of doing.</p><h3>1.6 <a href="https://parentheticallyspeaking.org/articles/us-cs-phd-faq/#(part._.Do_.I_need_to_go_for_a_.Ph.D_to_do_research__.Can_.I_do_it_in_industry_)" title="Link to here">🔗</a> </h3><p>Most industrial research is done by people who already have a PhD. It’s not a strict rule, and I know a small number of people in industry who do research without having earned a PhD; but the exceptions almost make the rule.</p><p>A PhD program also offers you a unique ability to work on a project for many years without worrying about immediate commercial impact and changing corporate priorities. Furthermore, you aren’t subject to a management structure where political and business decisions that have nothing to do with science can significantly alter or even drop your project. For these reasons, I think a PhD program is effectively unparalleled if you want to truly pursue research.</p><section class="SsectionLevel2" id="section 2" morss_own_score="6.85182049110923" morss_score="53.65843430779706"><h2>2 <a href="https://parentheticallyspeaking.org/articles/us-cs-phd-faq/#(part._.Before_.Applying)" title="Link to here">🔗</a> </h2><h3>2.1 <a href="https://parentheticallyspeaking.org/articles/us-cs-phd-faq/#(part._.Will_.I_be_funded_for_a_.Ph.D_)" title="Link to here">🔗</a> </h3><p>Yes, you will. There may be some fine-print about having to be doing reasonably well (you can’t do nothing, goof off completely, and expect to be paid indefinitely), but in summary: yes.</p><p>As of this writing (2022), you can expect to make about USD 30,000 (before taxes) for the academic year. This amount can vary across institutions, especially with differences in cost-of-living, which can vary quite a bit between different places. During the summer you may work with your research group, or you may take an industrial internship, or do something else. The details of that are something you work out with your advisor.</p><p>The funding can take several forms. Typically, it has names like “fellowship”, “research assistantship” (RA), and “teaching assistantship” (TA). A fellowship usually has fewest strings attached; an RA is usually tied to a specific project or grant; and a TA will require you to do some teaching-related work (helping students, grading, and so on). However, the lines between these are not necessarily very sharp, and sometimes money of one kind may be <span>labeled</span> as money of a different kind. Therefore, be sure to ask and make sure you understand what your obligations are irrespective of what name is being used.</p><p>If you are offered an unfunded position, you should not take it.</p><h3>2.2 <a href="https://parentheticallyspeaking.org/articles/us-cs-phd-faq/#(part._.How_long_does_a_.Ph.D_take_)" title="Link to here">🔗</a> </h3><p>In some countries, there’s a pre-defined bound on the length of a PhD. Not so in the US. Your PhD program will expect you to pass various milestones—</p><p>How long all this takes depends on many things: your background, your topic, your progress, and your luck. It is typical for students to finish in about 6 years. In the US, however, it is quite common for students to enter a PhD program directly after a bachelor’s degree. Students who enter with a master’s can quite likely reduce the time they take, but the total time may still be the same (and may even be a bit longer, if they change institutions).</p><h3>2.3 <a href="https://parentheticallyspeaking.org/articles/us-cs-phd-faq/#(part._.Is_a_thesis_different_from_a_dissertation_)" title="Link to here">🔗</a> </h3><p>Even though people use the terms interchangeably, they really are different terms that refer to two related but distinct concepts. Read and understand <a href="https://www.ccs.neu.edu/home/shivers/diss-advice.html">Olin Shivers’ Dissertation Advice</a>. Re-read it every few years until you finish your PhD.</p><section class="SsectionLevel3" id="section 2.4" morss_own_score="6.936794582392777" morss_score="31.028223153821347"><h3>2.4 <a href="https://parentheticallyspeaking.org/articles/us-cs-phd-faq/#(part._.How_do_.I_know_if_.I_m_ready_for_a_.Ph.D_)" title="Link to here">🔗</a> </h3><p>I can tell you when you should <span>not</span> apply for a PhD: when the only reason is because you don’t know what else to do. A few years into your PhD, when nothing is working and you feel miserable, you need a strong, affirmative reason for having gone there in the first place: that’s what powers you through the negative moments.</p><p>You might go to a PhD program because you have an advisor who says that’s the right path for you. There’s nothing wrong with that; I have several students who have gone directly to a PhD.</p><p>But the generic advice I give students is to <span>not</span> go directly to a PhD. Instead, go work in industry (or “industry”: anything that isn’t taking more courses). Get your hands dirty. Get some real experience with the world. This has two advantages.</p><p>First, you can earn real money. This is in no way financial advice, but you should think about how you want to factor this in. You may use it to help people (e.g., family) or pay off loans. Or you can just save it. As a computer scientist, you know how exponential functions work; the compound interest formula is an exponential function. If you save for retirement at 22, even if you don’t touch your money for 8 years, it has the potential to quietly compound in the background. And some spare cash can make graduate student life more comfortable.</p><p>Second, you’ll know why you are applying. I tell students, <span>Wait until you’re frustrated about something</span>. I don’t mean being frustrated at your boss; then you just need a different boss. But if you are frustrated by something <span>technical</span>,<span>I will use the term “technical” repeatedly. This should be interpreted broadly. It does not mean only, say, related to mathematics or systems. It can just as well be related to humans. It just needs to be the kind of problems that computer science departments solve.</span> now you have your motivation. You know what problem you want to solve. You can start to find papers on it. Papers you previously could not have understood will start to make sense. You’ll start probing the purported solutions. You’ll find who else works in this area. You can see which people are doing work that fits your tastes. And now you have: (a) a clear problem area, (b) concrete motivation for working on it, (c) a sense of what kind of solution will and won’t work in the original domain, (d) a list of people to apply to, and (e) a great outline of your statement of purpose.</p><p>Let’s say you never get frustrated. That means you’re well-paid and happy. Over 95% of humanity does not reach this state. Revel in it. Skip the PhD.</p><p>If you do apply for a PhD program after time spent in industry, look into the US National Science Foundation’s <a href="https://www.nsf.gov/cise/CSGrad4US/">CSGrad4US</a> program (if you are eligible).</p></section><h3>2.5 <a href="https://parentheticallyspeaking.org/articles/us-cs-phd-faq/#(part._.What_is_the__.Valley_model__)" title="Link to here">🔗</a> </h3><p>When I was a new international student, my foreign student advisor (Ann Quillen) talked to us about the phenomenon of “homesickness”. Right now, she said, you all feel euphoric about your new setting and think it won’t happen to you. Then she drew the following graph:</p><blockquote><p><img src="https://parentheticallyspeaking.org/articles/us-cs-phd-faq/mood.png"></p></blockquote><p>Her point was that every student goes through a similar swing. They start out euphoric; then reality sets in; then, when things get hard, they start to miss home. But then they eventually work things out, recover, and return to some state well above the trough; whether it’s at the same level as that initial euphoria, lower, or even higher, depends on the student. And of course this cycle could repeat.</p><p>That picture always stayed in my mind, especially when I found that it neatly matched my own experiences. (“Around October”, she had said, the decline would begin, and it did. Was it causal? I don’t think so.)</p><p>Many years later, I realized, something similar happens in a PhD program as well. You start out euphoric: new program, new people, new-found freedom, a stipend, and so on. Then you get into the rut of courses and projects, and the initial buzz wears off. Then your papers start getting rejected. First it seems program committees don’t care; then that other professors in your department don’t care; then even your advisor; and finally maybe even you.</p><p>When you reach this nadir, it’s essential to know <span>why you came to the PhD program in the first place</span>. If you came because it was the default option, this is the point where you decide to leave—</p><section class="SsectionLevel3" id="section 2.6" morss_own_score="6.958456973293769" morss_score="33.125123639960435"><h3>2.6 <a href="https://parentheticallyspeaking.org/articles/us-cs-phd-faq/#(part._.How_do_.I_find_the_best_professors_programs_~e2~80~a6_)" title="Link to here">🔗</a> </h3><p>This is the wrong question. Instead, I will give you a surefire way to figure out whom you should apply to.</p><p>First, how do you find the people who are doing things that are interesting to you? For that, you crack open conference proceedings. These days you can find just about all (especially recent) publications online, and very often you can get a free copy from an unofficial site. Read lots of papers. See which ones interest you. Of course, make sure what they are doing <span>now</span> still interests you, and check on where they even are today!</p><p>(You might wonder which proceedings to crack open. There are lots and lots of bad conferences out there. One simple litmus test is to see the institutional affiliation of the people publishing those papers. Are they from places you aspire to be at? If not, then you may have opened a poor-quality venue, perhaps even a predatory one. Close it, step away, and move on.)</p><p>You may, of course, be quite unable to read the technical heart of the paper. But you should be able to read and make some sense of the abstract and introduction. You should also see whether the kind of technical detail the paper has—</p><p>Then, once you’ve narrowed down a list of papers, look at who wrote them. Find the professors. Also locate the students, who may now themselves be junior professors.</p><p>These are the people you want to apply to.</p><p>You can, if you wish, “rank” them by whatever other criterion you want to use (location, prestige of the university, two-body constraints, etc.). How you do that is up to you. But this is the set you want to work from.</p><p>Yes, all of this takes a lot of work. But this is the rest of your life we’re talking about. If you’d rather delegate all the work to a rankings site, you’re welcome to, but don’t say you weren’t warned.</p></section><h3>2.7 <a href="https://parentheticallyspeaking.org/articles/us-cs-phd-faq/#(part._.What_areas_are_currently_hot_)" title="Link to here">🔗</a> </h3><p>“Hot” things in computer science—</p><p>If you still want to pursue what’s hot, go ahead! You’ll have to find an answer to your question elsewhere.</p><h3>2.8 <a href="https://parentheticallyspeaking.org/articles/us-cs-phd-faq/#(part._.What_do_.I_do_if_.I_m_interested_in_multidisciplinary_research_)" title="Link to here">🔗</a> </h3><p>It depends on the institution and the particular multidisciplinary perspective.</p><p>Given whatever your perspective is, see whether there is an entity at each university of interest that focuses on it. You may find a “Center for” or “Program in” or something of that sort. Sometimes these will admit students directly; quite often they will have a collection of affiliated departments and you will be expected to meet the admissions and PhD process of one of those departments.</p><p>The details vary significantly, and there is no shortcut to studying the counterparts at each institution. The advantage to this diversity is that each place is free to have its own program, and will have differences (some big, some subtle) that reflect that institution’s view of the field you’re interested in. You may find some of these programs are much more to your liking than others.</p><h3>2.9 <a href="https://parentheticallyspeaking.org/articles/us-cs-phd-faq/#(part._.Are_there_services_that_will_evaluate_my_application_s_chances_)" title="Link to here">🔗</a> </h3><p>There may very well be; the question is whether they are any <span>good</span>. I would <span>not trust</span> standard applicant evaluation services. Even if they are good at evaluating undergraduate applications (which is itself a big “if”), they are very unlikely to have the expertise to evaluate graduate applications. If they claim they do, ask them how they are able to anticipate how research university professors would read a dossier.</p><p>Even if they can perform a preliminary evaluation, they are unlikely to know about the spatial and temporal peculiarities of particular departments: What kind of applicant does this department like? What is the funding situation like this year? Things like that.</p><h3>2.10 <a href="https://parentheticallyspeaking.org/articles/us-cs-phd-faq/#(part._.Are_the_expectations_different_for_students_with_a_master_s_)" title="Link to here">🔗</a> </h3><p>Somewhat. Often, applicants may have a bachelor’s degree from a more obscure (to the reader) institution and a master’s from a less obscure one. The performance in the master’s then gives the reader a better sense of quality. In addition, the letters writers may be better known, and may hence be more trust-worthy. Finally, if the applicant did some research during the master’s, then what the research advisors say will matter a lot.</p><h3>2.11 <a href="https://parentheticallyspeaking.org/articles/us-cs-phd-faq/#(part._.Do_.I_need_to_know_what_area_.I_m_interested_in_when_applying_for_the_.Ph.D_)" title="Link to here">🔗</a> </h3><p>At many institutions, it really helps. Unless you are somehow an extraordinary generalist, many programs would prefer to see applicants who have at least some idea of what they want to do. If you have no idea about areas, one can also wonder whether you really are ready for a PhD yet. (That’s not entirely fair, but some people might wonder that anyway.)</p><p>Of course, you will hopefully be exposed to whole new areas during your PhD, and may find yourself migrating to them. But it still helps to have some clear direction to give your statement of purpose some real purpose. And in many departments, you probably won’t get admitted at all without a clear area.</p><h3>2.12 <a href="https://parentheticallyspeaking.org/articles/us-cs-phd-faq/#(part._.When_should_.I_start_thinking_about_applying_)" title="Link to here">🔗</a> </h3><p>Suppose you want to start your PhD in year <span>Y</span>. Then applications will be due late in the year <span>Y - 1</span>.</p><p>You should start preparing your application a lot sooner. You should work on your statements starting in the summer of <span>Y - 1</span>. If the universities you are applying to require you to take a standardized test, you’ll need to prepare for that and also set up the logistics of taking it.</p><p>You will need recommendation letter writers. Don’t spring requests on them at the last minute—<a href="https://cs.brown.edu/~sk/Memos/Grad-School-Recos/">Graduate School Recommendations Advice</a>. Here is the kind of information that I find useful from my students: <a href="https://cs.brown.edu/~sk/Memos/Reco-From-Me/">Recommendation Letter from Me</a>.</p><p>You will also have to arrange for the institution to receive other materials, such as your grade transcripts. That may take some time, especially if it requires translation.</p><h3>2.13 <a href="https://parentheticallyspeaking.org/articles/us-cs-phd-faq/#(part._.Can_.I_do_a_computer_science_.Ph.D_with_prior_degrees_in_a_different_subject_)" title="Link to here">🔗</a> </h3><div>Quite possibly. It depends on a few things: </div><ul><li><p>How close your previous degree was to computer science.</p></li><li><p>What you plan to study. The previous degree may actually help you: e.g., if you want to do computational biology and your previous degree is in biology, that can be to your advantage.</p></li><li><p>Whether you demonstrate the ability to do basic computer science. In particular, PhD programs often have coursework and distribution requirements; if you are not going to pass those, that would be problematic. One way you can demonstrate your ability, if you did not take computing courses in your prior degree, is through informal venues such as projects and MOOCs.</p></li></ul><h3>2.14 <a href="https://parentheticallyspeaking.org/articles/us-cs-phd-faq/#(part._.Can_.I_do_a_.Ph.D_in_computer_science_if_.I_already_have_one_in_something_else_)" title="Link to here">🔗</a> </h3><p>Quite likely. Some institutions may have rules against a second PhD, so double-check. But many people have done this.</p></section><section class="SsectionLevel2" id="section 3" morss_own_score="6.950011901928112" morss_score="55.336653356334075"><h2>3 <a href="https://parentheticallyspeaking.org/articles/us-cs-phd-faq/#(part._.Ph.D_.Application)" title="Link to here">🔗</a> </h2><h3>3.1 <a href="https://parentheticallyspeaking.org/articles/us-cs-phd-faq/#(part._.What_is_the_timeline_)" title="Link to here">🔗</a> </h3><div>There’s a fairly typical timeline for applications: </div><ul><li><p>The application deadline will most probably be sometime in the month of December, but some places may have earlier or later deadlines. There is no firm agreement on this, so you need to check each place you are interested in separately.</p></li><li><p>Folders will be read soon after they come in. This means incomplete folders will be at a disadvantage. At institutions with lots of applicants, people may not have time to go back and read a folder several times as each piece comes in. This means you have to make sure your letter writers were informed well enough in advance so that they got their letters in before the deadline!</p></li><li><p>Decisions are usually made in late-January or February. It’s rare for decisions to be announced later than February, but you can expect them to come out at various points during that month.</p></li><li><p>Many institutions have only one round of decisions, but there are cases where there might be a waitlist. However, these seem to be rare.</p></li><li><p>With your admission, you will be given information about financial aid and also be invited to learn more about the department. Often you will be given an offer to fly out to visit (you should be reimbursed at least partially, with the expectation that you combine visits to multiple universities and the collective reimbursement covers all your costs).</p></li><li><p>Usually, when you’re invited to visit, you have already been admitted. Sometimes, you be asked over for an <span>interview</span> instead. Make sure you know which it is; if in doubt, ask! But even if you’ve been admitted, remember that you’re making the first acquaintance with the person who may be your PhD advisor, a relationship for life. Approach it professionally. And remember, now the shoe’s on the other foot: <span>they</span> are trying to convince <span>you</span> to come there!</p></li><li><p>You will be asked to respond by April 15. This is a standard date that has been <a href="https://cgsnet.org/resources/for-current-prospective-graduate-students/april-15-resolution/">pledged</a> by all major universities. You should not be pressured by anyone to accept <span>before</span> that date.</p></li><li><p>Once you have accepted an offer from one institution, decline the offers from the others. Don’t try to play games. It rarely ends well.</p></li></ul><h3>3.2 <a href="https://parentheticallyspeaking.org/articles/us-cs-phd-faq/#(part._.What_is_the___300_000_model__)" title="Link to here">🔗</a> </h3><p>A common mistake applicants make is to ask a potential advisor, “Will you accept me?”, or “Can you fund me?” Here’s why these are not good questions.</p><p>I tell students to follow the “$300,000 model”. That is, when you approach a potential advisor about being an advisee, what they see is not only a human being; they also see, floating above that person, a number like this:</p><blockquote><p><img src="https://parentheticallyspeaking.org/articles/us-cs-phd-faq/person-300.png"></p></blockquote><p>$300,000 is’s roughly what it takes to fund one PhD student for about 5 years. (You don’t get all of it, though!) So you’re asking them whether they are willing to raise that much money. You are <span>also</span> asking whether they’re willing to undergo the opportunity cost of having taken you instead of some other student for that duration.</p><p>Now, it is <span>extremely</span> easy to read this the wrong way, especially if you are a little low in confidence for any reason. Do <span>not</span> read this as “Am I worth $300,000?” Rather, read it as, “How do I demonstrate that I am worth $300,000?” You do not have to have a perfect response. You just need to be aware of what may go through an advisor’s mind, and craft your approach accordingly.</p><p>Most of all, do not read this and talk yourself out of applying! Too often I see people make decisions that it’s others’ job to make. Deciding whether or not to admit you is the job of the PhD admissions committee, not yours! You do your job (apply well); let them do their job. Don’t do their job for them.</p><h3>3.3 <a href="https://parentheticallyspeaking.org/articles/us-cs-phd-faq/#(part._.Who_reads_application_folders__.Is_it_the__.Graduate_.School__)" title="Link to here">🔗</a> </h3><p>The reality is this. Technically, you are admitted by some formal entity like a Graduate School. However, your admissions decisions are actually made by professors in the department. That is, your folder is usually read by professors who will eventually work with you, not entities abstracted from the day-to-day execution of research. This plays into how you write: you are not writing for administrators, you are communicating directly with your intended advisors and people like them.</p><p>Within a department, responsibility is usually divided between an admissions committee and individual faculty members. The details vary a lot between institutions and over time. However, in general, the committee is responsible for general oversight, maintaining standards across the board, managing the number of admits relative to funding, etc. But very often, individual faculty members or groups will make decisions about “their” applicants (though this is not universally true). Those who don’t fall to any particular group or groups will likely be decided on by the admissions committee.</p><h3>3.4 <a href="https://parentheticallyspeaking.org/articles/us-cs-phd-faq/#(part._.Is_the_.G.R.E_important_)" title="Link to here">🔗</a> </h3><p>Universities are increasingly de-emphasizing standardized testing scores like the GRE. Therefore, this question is increasingly moot.</p><p>My personal view is that for some students, the GRE cannot help, only hurt; for others, it can help.</p><p>If you come with a prior record that we can “understand” (e.g., we recognize the institution, understand its grading standards, etc.), then we already have a ton of information about you. If your grades are poor, one GRE score is not going to reverse that. If your grades are good, a good GRE gives us no new information, while a poor GRE only casts some doubt. So there’s no real point to taking the GRE.</p><p>If you come from an unrecognized environment, then we have no calibration for how good you are. The value of a <span>standardized</span> test is that it gives us some calibration. Thus, a good GRE performance can help you (slightly). It’s unlikely on its own to make the difference between admission and rejection, but if you are close to the line and people want reassurance, it can provide them that reassurance.</p><section class="SsectionLevel3" id="section 3.5" morss_own_score="6.962466487935657" morss_score="40.58746648793566"><h3>3.5 <a href="https://parentheticallyspeaking.org/articles/us-cs-phd-faq/#(part._.Does_the_.G.P.A__grade_point_average__matter_)" title="Link to here">🔗</a> </h3><p>What do you think?</p><p>Of course it matters…for the most part.</p><p>Your GPA gives us several useful cues. It tells us that you are competent at the relevant disciplines. It tells us that you can do steady work. It tells us that you’ve picked up various skills. A poor GPA can suggest that one or more of these is not true.</p><p>However, there are five caveats.</p><p>First, we are primarily interested in your grades in <span>relevant</span> courses. If you do well at math and poorly at underwater basket weaving, unless the latter is deeply relevant to your specific academic interest, we don’t care. In that sense we’re more interested in your subject/major GPA than overall GPA, though if you do poorly at all writing-related courses, some professors (like me) would be worried, because ultimately you have to do a fair bit of (paper) writing as a PhD student.</p><p>Second, we are interested in your trend. If you start out poorly, then hit your high gear, and end on a high note in your last year or two, that’s great, and that can forgive a lot of poor early grades. If you do the opposite, that’s really worrisome.</p><p>Third, we’ve all screwed up now and then. (Please don’t ask me about <span>that</span> semester…) A glitch here and there is unlikely to be a big deal. It’s more worrisome if you flubbed courses that are directly tied to the very thing you seem to be passionate about working on, less so otherwise.</p><p>Fourth, we can all suffer from some mishaps. You may have had an illness, had a family member with an illness, had to support someone, etc.</p><p>Finally, you may be someone who’s just not very good with the conventional academic system but are actually an outstanding researcher.</p><p>Especially in the latter categories, your application needs some explanation: what’s on paper is not the whole story. There are three main sources of explanation.</p><p>The first is yourself. You can tell us about it in your statement of purpose. The second is your letter-writers. Especially in the last (“tortured genius”) category, they can tell us to disregard your grades by marshaling other evidence about you. The third is your accomplishments: you may have built projects that better showcase your abilities than your coursework does. These you can document through a dossier and a reference in your statement of purpose.</p></section><section class="SsectionLevel3" id="section 3.6" morss_own_score="6.974121996303142" morss_score="36.11048563266678"><h3>3.6 <a href="https://parentheticallyspeaking.org/articles/us-cs-phd-faq/#(part._.Does_prior_research_experience_matter__.What_if_.I_haven_t_any_)" title="Link to here">🔗</a> </h3><p>Yes, it can. The more competitive the university, the more it can matter.</p><p>In principle, a PhD program exists to teach you how to do research. But if a professor can get a student who already has some experience doing it, wouldn’t (all else being equal) they prefer such a student? <span>Any</span> skill they can get you with some prior preparation on is a skill they can spend that much less time teaching you, letting you progress farther and deeper.</p><p>However, the <span>worst</span> thing you can do in response to this is to rush to “publish a paper”. There are far too many <span>predatory publishers</span> who will gladly let you have “a paper” in return for some money. These papers are not worth the bits they are stored on. They won’t fool any admissions committee. You won’t get in just by publishing at a bunch of no-name conferences: there’s no algorithmic filter that you’re fooling. You’re just wasting your time, enriching scoundrels, and deluding yourself (as you will find out a few months later, when the rejections arrive). <span>Do not fall for this</span>.</p><div>If you can get a “real” paper—</div><ol><li><p>Publishing as an undergraduate is very hard. You may not have the subject background, you may not know the research methods, and you probably don’t know how to present it even if you get past the other two obstacles. Simply writing up something and sending it to a prestigious venue wastes everyone’s time. Most undergraduates, if they publish major results at all, do so working closely with faculty, PhD students, and post-docs who already know the ropes.</p></li><li><p>Simply being “published”, even at a legitimate venue, may not mean much. What a professor will want to know is what your role was. Were you an intellectual leader? Or did you simply write some scripts? There is absolutely nothing at all wrong with the latter, but it makes your “publication” count less from the perspective of judging your research abilities.</p></li></ol><p>So, we come to the crux: most undergraduates will not have a meaningful research publication. What else can you do to demonstrate your skill?</p><p>Well, ask yourself: what can <span>you</span> do? Perhaps you can create a blog of the papers you have read with good summaries of each paper. Perhaps you can reimplement an algorithm from an interesting paper and benchmark it. Perhaps you can create a neat project that showcases your abilities. Perhaps you can generate interesting follow-up questions on a paper that intrigued you. Perhaps you can even prototype some follow-ups and see where they lead. Perhaps you can complete some MOOCs on subjects you were missing.</p><p>In the end, the more competitive the place, the more professors are looking for students to have some “fire in the belly”. A student who simply did well in all their courses but took no further initiative often suggests that they are good at following rules, but may not become a leader. Are you just a rule-follower or do you have a burning passion to advance the field? Demonstrate that passion in a technical way!</p></section><h3>3.7 <a href="https://parentheticallyspeaking.org/articles/us-cs-phd-faq/#(part._.How_do_.I_think_about_my_letters_of_recommendation_)" title="Link to here">🔗</a> </h3><p>The most important thing to understand is that, collectively, your letters have to tell a story about you. Therefore, think about the different facets you want to highlight and find people who can address each one.</p><p>Your letters do not all have to come from professors. Letters from others can also be very useful, and a quality non-professor letter can be much more useful than a perfunctory one from a professor. Others usually includes post-docs you may have done research with or bosses in industry. This comes back to documenting your facets.</p><p>Normally, we care about your <span>technical</span> facets, not (for instance) about your volunteer work. However, it depends on what you’re applying for. if you want to do research in villages in the developing world, then time you spent with a non-profit actually making a difference in villages is much more useful than a routine professor letter.</p><p>Unfortunately, many people (professors included, but especially non-professors) do not know how to write very good letters. This is true of younger researchers (like post-docs), people in industry (where a letter serves a very different purpose), people in non-profits (ditto), etc. Therefore, if you can, please try to have your letter-writers read <a href="https://cs.brown.edu/~sk/Memos/Grad-School-Recos/">Graduate School Recommendations Advice</a>.</p><p>Finally, don’t worry if not all of your letter-writers can write about you in depth. We understand that you may not be able to make three deep contacts, especially at large institutions. The more the better, but a primary letter that will talk about you in depth, along with supporting letters, is fine. This is why it’s important to think about the <span>collective</span> story, not focus on each letter independently.</p><h3>3.8 <a href="https://parentheticallyspeaking.org/articles/us-cs-phd-faq/#(part._.How_does_industry_experience_translate_)" title="Link to here">🔗</a> </h3><p>Industry experience is virtually never bad. At worst, it’s neutral (unless you did something horrible). Often, it’s a tiny boost: it suggests you have some skills (working with large systems, working in teams, being organized, etc.) that many students coming directly out of an undergrad degree don’t have. Sometimes, it can be a big boost, if your industrial work is directly tied to your application goals. It is then especially important to highlight your industrial work in your statement of purpose.</p><section class="SsectionLevel3" id="section 3.9" morss_own_score="6.975986277873071" morss_score="39.14265294453973"><h3>3.9 <a href="https://parentheticallyspeaking.org/articles/us-cs-phd-faq/#(part._.What_makes_for_a_good_and_bad_statement_of_purpose_)" title="Link to here">🔗</a> </h3><p>Who’s reading your folder? Your potential PhD advisor and people like them. So you are writing for a technical audience. They are also busy, reading lots of folders and trying to triage which ones need more attention. Apply the <span>one minute test</span>: if a person spent one minute reading my statement, would they feel intrigued enough to keep reading?</p><div>It’s easy to say what you should <span>not</span> do. Here are several tips: </div><ul><li><p>Don’t start off with a story about how you got your first computer when you were five. They don’t care. If anything, many of them most certainly did not, so you had a huge head start on them; they would then expect to see you have done a lot more than they did when they applied to graduate school!</p></li><li><p>Don’t tell them about your family’s devotion to education and so forth. It doesn’t matter. If your family are devoted, that’s great. If they are not, kudos to you for aspiring for an education anyway. But either way, it doesn’t help people determine whether you should be admitted.</p></li><li><p>Avoid buzz-words and trendy marketing-speak. You aren’t trying to sell them a database or cloud service. You’re trying to convince them you have enough technical depth to do a PhD.</p></li><li><p>Don’t italicize and bold-face every buzz-word and trendy marketing-speak. It makes the previous problem much worse.</p></li><li><p>Don’t tell them how wonderful their institution or location is. They know! That’s why you’re applying there. But that’s also why lots of other people are applying there. You want to convince them to admit you over the others.</p></li><li><p>Don’t spend a lot of space on personal tales of woe. They do want to understand you the person. But within limits.</p></li></ul><p>Okay, with that out of the way: what <span>should</span> you do?</p><p>Open with a clear statement of your interest.</p><p>Tell them about relevant background. If you have a mix of academic and non-academic background, summarize both. If you think they wouldn’t have heard of your institution, tell them a bit about it (e.g., does it have any designation of merit in your country?).</p><p>Tell them about moments of epiphany. What in computer science sparked joy in you? Why? And what did you do about it?</p><p>If you have prior research or project experience (whether published or not), tell them about it. Anything that is interesting, difficult, and compelling can fit here. Focus on what you contributed to it. If it was done under someone’s supervision, they would expect to see a letter from the person who supervised it, and hopefully the letter confirms what you claim—</p><p>Most of all, tell them why you’re applying to them and what you want to do there. State your <span>purpose</span>. This is where you describe faculty who you find interesting; tell them <span>why</span> they interest you. The more depth you can provide here, the better. If it looks like you just looked at the Web page and picked off everyone in an area, that is not very persuasive; if you can say something of substance, that makes clear you have actually bothered to understand a person’s work, you are much more likely to get their attention.</p><p>Finally, if you have any mitigating issues, you can mention them briefly. For instance, if you had an illness that hurt your performance in one semester, you can tell the reader that. You don’t have to reveal private details; also, keep this portion relatively short. People want to give you a fair chance, but they don’t need to read an entire saga.</p></section><h3>3.10 <a href="https://parentheticallyspeaking.org/articles/us-cs-phd-faq/#(part._.What_is_a__portfolio__)" title="Link to here">🔗</a> </h3><p>A portfolio is a range of products. When you apply to an arts program, for instance, you are often required to submit an impression of various artwork you have created, to give people an impression of what you’re capable of.</p><p>Computer science students, especially PhD applicants, don’t realize this, but we too (can) have portfolios.</p><div>The most obvious components of a portfolio—</div><ul><li><p>Significant course projects.</p></li><li><p>Research projects.</p></li><li><p>Independent projects that you created not because anyone asked or paid you to, but because you were excited about something.</p></li><li><p>Performance in courses outside conventional education, whether summer schools or MOOCs or other opportunities.</p></li></ul><div>and so on. Note that many of these are already mentioned in other parts of this document. The aggregate of all these is your portfolio. Some parts may be PDF documents, other parts may be on code repositories. Make clear what they are and how to find them in your application. A potential advisor will often spend as much time on these—</div><h3>3.11 <a href="https://parentheticallyspeaking.org/articles/us-cs-phd-faq/#(part._.What_if_my_prior_education_isn_t_from_a_well-known_university_)" title="Link to here">🔗</a> </h3><p>This is a hard question without a good answer. I’m afraid I don’t have great news here.</p><p>The thing to understand is that ultimately, the PhD admissions process is a process of trust. We get grades, letters, and other artifacts, and we have to know how to evaluate them. If we’ve never heard of your university, or don’t know the standards of your professors, it’s very hard to evaluate what they are saying. All transcripts have courses with similar <span>names</span>, but the same course could be much easier at one university and much harder at another. When a professor signs off a letter saying “You would be making a mistake to not accept this student”, it means much more coming from a peer whose standards we know to be very similar to our own than from someone whose standards we can’t judge.</p><p>Therefore, if you start out with these disadvantages, you likely need to moderate your reach. You can’t expect extremely competitive universities, with lots of very strong applicants, to spend much time over your application. You are probably best off lowering your sights, perhaps going to a less strong place initially, impressing, and working your way up. There are many stages on the professional ladder: master’s, PhD, possibly post-doc, maybe even faculty position (depending on your plans). If being at very competitive places is what matters to you (and there’s no reason it should!), you have the potential to go to progressively more competitive places at each stage.</p><p>Of course, there are things you can do to try to counteract your weakness. Assemble the best portfolio you can! It may give you a longer look (and perhaps even success) at a much more competitive department, and it may be the thing that gets you into a less competitive one.</p><section class="SsectionLevel3" id="section 3.12" morss_own_score="6.9753086419753085" morss_score="34.641975308641975"><h3>3.12 <a href="https://parentheticallyspeaking.org/articles/us-cs-phd-faq/#(part._.Should_.I_contact_professors_and__if_so__how_)" title="Link to here">🔗</a> </h3><p>Ah yes, a vexing question.</p><p>In the grand sum of things, contacting professors will largely make no difference. It can help a little, and it can hurt a little. Professors are busy, and they want to spend their time on the students already at their university. For some professors, if they were to reply to every inquiry, that’s literally all they would do all day, and they wouldn’t be able to do their job. Think of it this way: if you were someone’s PhD student, would you want them spending time on you or on applicants? So don’t get offended if you don’t hear back. Email overload is a real thing.</p><p>Why can contacting be helpful? If you get on a professor’s radar—</p><p>However, make sure you have something of value to say. Keep in mind the $300,000 model. Keep it short. Be concrete. Don’t tack on lazy questions at the end that you think make you sound inquisitive but are actually really vague and will take a long time to respond to. It’s exciting when someone has clearly read your work and asks hard, probing questions; but if all you do is ask perfunctory questions, you’ll give the impression of either not being able to read the papers or not caring to, and neither is going to elevate you.</p><p>In particular: <span>if your message looks like a form letter, it will be ignored</span>. And believe me, professors have gotten very good at spotting (what they think are) form letters. Your one or two lines of customization, using text copied from the Web, won’t fool them. And anyway, it doesn’t matter whether or not they were right: if it <span>looks</span> like a form letter to them, you have failed to meet your objective.</p><p>Finally, see whether the professor provides instructions on the Web about contacting them. If they do, <span>follow the instructions</span>! If you don’t, you will certainly not help, and may hurt, your application. Some professors, for instance, have email filters aligned with their instructions, so even how your email is routed depends on whether you followed the instructions.</p><p>Ultimately, the extent to which writing can help depends to some extent on two factors: one is the visibility (often aligned with seniority) of the professor and the other is the tier of the institution. The better-known the professor and institution, the more high-quality applicants they have, and the less they need to look for students. (But even renowned professors at very competitive institutions don’t want to miss out on an exceptional applicant!) The less either one is true, the more likely they are to be open to students contacting them. At less competitive places, professors probably get fewer inquiries and student quality may be weaker, so they may be much more interested in hearing from applicants. But keep in mind they too are busy and have lots of email, so the same general principles apply.</p><p>It is also perfectly fine to not contact any professors. In principle, just applying should suffice. However, (a) check their page: if they <span>want</span> you to contact them, then you definitely should; (b) the one place it does help, as noted above, is to make sure your application is brought to their attention if there’s a particularly good reason for that.</p></section><h3>3.13 <a href="https://parentheticallyspeaking.org/articles/us-cs-phd-faq/#(part._.Should_.I_have_a_backup_school_)" title="Link to here">🔗</a> </h3><p>What’s your goal? If your goal is to get into some PhD program, you may very well be able to. That’s not a very good goal. If your goal is learning, then the notion of a “backup” doesn’t quite make sense. Of course, once you’ve identified professors of interest, they may well be at universities at different levels of competitiveness, and the less competitive ones may feel like a “backup”. Not only is that not a “backup” in the generic sense, you may also be surprised after visiting all the places you get into to find that the “backup” is actually the most pleasant of the lot, and where you want to go!</p><h3>3.14 <a href="https://parentheticallyspeaking.org/articles/us-cs-phd-faq/#(part._.If_.I_m_asked_to_interview__how_do_.I_prepare_for_it_)" title="Link to here">🔗</a> </h3><p>Interviews don’t seem to be common, but they also aren’t unprecedented. They may be more or less formal: a set of structured questions, or just a call from a professor wanting to chat with you (before they make a final decision).</p><p>The reasons to interview could be manifold. They may want to learn more about things that weren’t covered in your application. They may be confirming things you did cover in your application. They may have a specific question about a particular project you did or a skill they want to confirm you have. Or they may just want to confirm that you are indeed as amazing as you seem on paper!</p><div>The two things you can do to prepare are: </div><ol><li><p>Remind yourself of what the professor does. If indeed it’s a true interview, coming across as unprepared will not help.</p></li><li><p>Remind yourself of what you wrote in your application. Sometimes applicants literally just forget what they said: they may have read something recently and been excited about it and said it in their statement, and then forgotten all about it. Your caller should not know more about your application (excepting, of course, the confidential parts, like recommendations) than you!</p></li></ol><div>It goes without saying that if you have been given instructions by the interviewer (e.g., to read some material), make sure you follow them!</div></section><h2>4 <a href="https://parentheticallyspeaking.org/articles/us-cs-phd-faq/#(part._.After_.Admission)" title="Link to here">🔗</a> </h2><h3>4.1 <a href="https://parentheticallyspeaking.org/articles/us-cs-phd-faq/#(part._.What_are_the_stages_of_a_.Ph.D_program_)" title="Link to here">🔗</a> </h3><p>Every institution is somewhat different. Once you’re admitted to a program, you can learn more from them directly.</p><h3>4.2 <a href="https://parentheticallyspeaking.org/articles/us-cs-phd-faq/#(part._.Should_.I_work_with_a_junior_or_senior_faculty_member_)" title="Link to here">🔗</a> </h3><p>There’s no single good answer to this. Stereotypically, junior faculty may spend more time with you and have more cycles to devote to you; senior faculty may be a little less hungry for success and may have more demands on their time. Which you prefer is up to you. Of course, junior faculty have less job stability; but senior faculty also move voluntarily, so you shouldn’t assume that a person will forever be at the same place. Usually, when people move, they and the current and new departments will work to make arrangements for students.</p><p>Ultimately, what matters is not whether a person is junior or senior; it’s the person themself. Ignore superficial markers and stereotypes. Get to know the person.</p><h3>4.3 <a href="https://parentheticallyspeaking.org/articles/us-cs-phd-faq/#(part._.Wouldn_t_it_be_awesome_to_enter_with_a_multi-year_fellowship_)" title="Link to here">🔗</a> </h3><p>Yes…and no.</p><p>Let’s say you win a fellowship such as the US National Science Foundation’s Graduate Research Fellowship. This gives you three years of funding. That relieves your advisor of having to find that amount of funding for you. The $300,000 sign vanishes. All good, right?</p><p>Yes, it’s good, in three ways. First, there is usually some prestige associated with such fellowships. Second, it may make you attractive to more advisors (in particular, ones who are currently in a funding trough). Third, your advisor can spend more time advising you and less time raising money for you.</p><p>However, it comes with a peculiar danger. This is that your advisor may stop thinking about you as much as if they were seeing you on their accounting ledgers all the time. This may enable you to “float” for a while. And then, when your funding runs out, they might look up and realize they have no idea what you have done and have not raised funds for the rest of your program.</p><p>Therefore, if you have one of these fellowships, it’s in your interests to keep your advisor just as focused on you as they are on students they are paying for. Also, a healthy period—</p><h3>4.4 <a href="https://parentheticallyspeaking.org/articles/us-cs-phd-faq/#(part._.How_can_.I_expand_the_network_of_people_.I_know_in_the_field_)" title="Link to here">🔗</a> </h3><div>There are numerous ways to build up your professional network. In a field that I know well, programming languages, here are at least four good ways: </div><ul><li><p>Regional conferences like NJPLS and NEPLS. They are very cheap to attend and you’ll form friendships with fellow students at other institutions. Then, when you all attend a major conference for the first time, you won’t know <span>nobody</span> in the room; you’ll at least have each other for moral support!</p></li><li><p>The SIGPLAN-Mentoring program.</p></li><li><p>The Programming Languages Mentoring Workshop.</p></li><li><p>The PLTea student group.</p></li><li><p>Doctoral symposia.</p></li></ul><div>and quite possibly many more. Find similar events in your area.</div><h3>4.5 <a href="https://parentheticallyspeaking.org/articles/us-cs-phd-faq/#(part._.Who_can_help_if_.I_have_problems_)" title="Link to here">🔗</a> </h3><p>If it’s internal to your department, you are best off finding support within the university. There are whole support structures available at US universities.</p><p>If you have an unfortunate incident at a conference, look to see whether your community has a CARES group, which now exist for many areas. People in CARES can help you navigate the ropes. Technically CARES groups are run by ACM SIGs, so they can be of only limited help at non-ACM events, but CARES members are senior and know a lot of people in the community, so let them try to help you.</p><h3>4.6 <a href="https://parentheticallyspeaking.org/articles/us-cs-phd-faq/#(part._.Is_the_.Ph.D_really_as_miserable_as_people_make_it_out_to_be_on_.Twitter_)" title="Link to here">🔗</a> </h3><p>Not at all. Social media are highly performative. They are also not a representative cross-section of life.</p><p>Are there issues with PhD programs? Sure. Are all of them getting the attention they deserve? Probably not. But there are also lots of well-run programs, happy students, and professors and institutions who are doing their best (with various constraints, not always visible on the outside) to run things well and make things better. Don’t let social media destroy your optimism and joy about further learning.</p></section>